<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <meta http-equiv="Content-Style-Type" content="text/css">
  <title></title>
  <meta name="Generator" content="Cocoa HTML Writer">
  <meta name="CocoaVersion" content="1038.32">
  <style type="text/css">
    p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.5px Times; color: #232020}
  </style>
</head>
<body>
<p class="p1">Our purpose here is to illustrate how the challenges of large-scale ubiquitous computing can be tackled with a structured, flexible approach to context. The key lies in providing an ontological foundation, an architectural foundation, and an approach to adaptation— all of which scale alongside the richness of the environment.</p>
<p class="p1">Ubiquitous computing embraces a model in which users, services, and resources discover other users, services, and resources, and inte- grate them into a useful experience. The two critical processes are to recognize users’ goals and activities, and to map these goals and activ- ities adaptively onto the population of available services and resources [5]. Context informs both recognition and mapping by providing a structured, unified view of the world in which the system operates. This is an ambitious goal, especially compared to current systems that need extensive manual configuration. The fol- lowing examples make the challenges concrete.</p>
<p class="p1">The Hearsay service developed as part of the GLOSS project allows users to pick up small notes left for them in the environment [2]. It makes sure users will find the message only if their context is correct (right person in the right place at the right time). The same approach is applied to other applications, providing a structured link between environment and behavior to improve util- ity and usability. In Figure 1, the computer-vision system used to identify and track the objects manip- ulated by Bob and Jane determines what to look at (the objects) and how to interpret (movement, loca- tion) based on the context (Bob and Jane’s activity).</p>
<p class="p1">By approaching the active map, Bob dynamically creates an interactive space from a public hot spot and a private device (Figure 2). Here, the system detects the presence of Bob and his device, it under- stands that Bob is willing to use the service of the active wall, and it both accommodates the diversity of private devices and provides its own services (for example, printing). In particular, the user interface of the inquiry service must dynamically distribute itself among the resources of the interactive space and dynamically adapt to Bob’s private device with- out creating confusion and distraction.</p>
<p class="p1">These simple examples illustrate three issues. Firstly, context is not simply a state but part of a process. It is not sufficient for the system to behave correctly at a given instant: it must behave correctly during the process in which users are involved. Cor- rectness must be defined with reference to the process, not simply the succession of states making</p>
<p class="p1">up that process. The printing ser- vice might be able to select the nearest (“correct”) printer at any given point, but if the user is mov- ing while printing a set of docu-</p>
<p class="p1">ments they may end up dispersed across a bewildering range of printers regardless of the indi- vidually correct point choices.</p>
<p class="p1">Related to all of this is the issue of a holistic treat- ment of context. The “best” adaptation (by what- ever metric) will typically be determined by a fusion of information, often crossing semantic levels. Using the printing service example, the system will select a “correct” printer for documents if it knows the user’s eventual location (perhaps derived from a diary entry for a next meeting) and can route docu- ments to the printer nearest to this location. This view of context-as-process is more flexible than the simpler view of context-as-state, and makes clear the utility and usability of a system are derived from the emergence of information and cooperation rather than the sophistication of its individual compo- nents.</p>
<p class="p1">The third issue is the risk of engendering a mis- match between the system’s model of interaction and users’ mental model of the system. For example, how do Bob and Jane know the system understands what they are doing? How can Bob predict (and pos- sibly control) the location of his printed document? In the conventional GUI genre, designers have typ- ically developed prepackaged solutions for a prede- termined interaction space. In ubiquitous computing, the interaction space is ill-defined, unpredictable and emerges opportunistically. In</p>
</body>
</html>
